What

Centralizes the repeated u64 -> little-endian limb decomposition that was open-coded across ~20 VM trace tables into two helpers in prover/src/tables/types.rs:

pub fn dword_wl(x: u64) -> [FE; 2]   // [x[0..32], x[32..64]]        (DWordWL)
pub fn dword_hl(x: u64) -> [FE; 4]   // [x[0..16], .., x[48..64]]    (DWordHL)

Call sites destructure and assign, so only the decomposition is dedup'd — the column assignments stay explicit:

let [pc_0, pc_1] = dword_wl(op.pc);
data[base + cols::PC_0] = pc_0;
data[base + cols::PC_1] = pc_1;

Why plain functions, not methods on Table

The limb width is field-size-specific: FE::from(u64) reduces mod p, so a 32-bit limb is only faithful because Goldilocks is ~64-bit. On a ~31-bit field (e.g. BabyBear) it would silently corrupt. So this belongs in the prover (which fixes the field), not the field-generic Table<F> storage type.

Scope

Converted only consecutive-column FE writes (verified consecutive in each cols module). Deliberately left as-is: parametric column indices (cols_i[..], lo_col), DWordWHH (Word+Half+Half) groups, byte/nibble splits, sign-extended [u64; 8] arrays (mul), and [u16;4]/[u32;4] bus/struct arrays.

Correctness

Byte-identical trace output. cargo test -p lambda-vm-prover --lib: 416 passed; the only 5 failures are *ecsm* prove tests that fail identically on main (pre-existing UnknownSyscall in the executor, upstream of trace generation). cargo fmt + cargo clippy clean.

Relationship to #693

Supersedes #693 (the original set_limbs_* approach) — part 1 of 2. Part 2 is a separate PR that makes Table.data private and routes the post-build multiplicity updaters through set_main (fixing a latent disk-spill hazard).